WDYT of implementing a simple "json flag" abstrraction like this? There are some advantages:

• Clearer error handling. If the JSON is bad it will fail on startup, not here
• Cleaner logic here, no need to handle parsing
• Minor: A bit more performant since we're not parsing the flag every time

Edit: Just saw that this inline edits the consts declared in this file. I'd say that's a sub-ideal since we now have consts that are not really the values that might be used in runtime. Some of the advantages I made above don't make sense as I guess this logic is run only once, so nevermind the JSON flag if you stay with this approach.

OTOH I think mutating the static variables can be a little error prone and harder to understand/debug. We now have "consts" in the file that are not really what might be used in runtime. A cleaner logic IMO would be to hold on to the override map in the docker manager instead, and change the getContainerImageName function to handle the override map instead. I think the logic might be simpler to understand as well. WDYT?

Good point and solution thanks!

I think the override JSON format could be improved to avoid multiple conflicts here. We have 3 different identifiers as keys on the same map:

• the special base image name which is used as the default here
• the batch pipeline image names (which comes from the pipeline_id)
• the live pipeline image names (which comes from the model_id)

All of these values could conflict with each other. I think we could have a layered JSON and avoid this, like:

type ImageOverrides struct {
    Default string
    Batch map[string]string
    Live map[string]string
}

Then we access each of them independently. WDYT?

Love it 😍. I did briefly have just this but then removed it again to keep changes minimal.